This PR adds the current research notes for /notifications around issue #350.

This research is about what the current code does today. Right now the RFC text is
still narrower than the code in a few places. The gap shows up in the
notification types, the request body, binding, discovery, and also in what it
should mean when a server says it supports notifications.

The notes in this PR look at:

• Nextcloud server
• Nextcloud Talk
• oCIS / reva
• cs3org / reva
• openCloud / reva
• OpenCloudMesh GO (I forgot to do it in time 😄 would add later)

The goal is to keep the public notes easy to read, while still keeping the main
implementation facts that may matter later for spec work.

Main Things Seen

• The current draft still reads mostly like an accept and decline callback
  story, while spec.yaml already lists more file-share notification types.
• Nextcloud server has a real receive path and real state changes, but the
  behavior is split across the main OCM route, older OCS fallbacks, and some
  app-specific paths.
• Nextcloud Talk uses the same endpoint as a real event channel for
  talk-room, so /notifications is already more than a file-share path.
• oCIS / reva supports a smaller file-oriented surface and makes different
  choices for binding and permission updates.
• Upstream reva and the inspected openCloud / reva path show that exposing
  /ocm/notifications and returning 201 Created still does not say much by
  itself about what is really handled behind the route.

Common Points In The Code

The request body keeps coming back. The RFC and spec.yaml do not line up very
well on required fields, and the code reads more like "notification object
required" than "mostly optional".

Binding also keeps coming back. Nextcloud mainly uses
notification.sharedSecret. oCIS / reva leans more on grantee, providerId,
and protocol. This changes how two servers decide that a notification points
to the same earlier share state.

Discovery is still uneven. Some servers advertise notifications, some do
not, some expose the route without advertising it, and some add extra legacy
names.

The scope is also wider than I thought. The endpoint already
carries file updates, calendar sync, and Talk room updates, so the spec may
need a cleaner way to separate a small shared core from resource-specific
behavior.

Receiver behavior is another repeated point. Malformed request, sender trust,
object binding, and actual state change are different stages, but the current
text does not separate them very well.

What Is In This PR

• add public research notes under work/notifications/research
• keep per-platform notification types and main code paths in the platform
  notes